The acceptance of wireless devices as a preferred personal communications medium has created a growing demand for such devices. Users of such devices also increasingly expect more functionality and a broader range of services to be made available through such devices. Not only is there a demand for more functionality, there is also a demand for faster response times and more efficient access to remote services.
A major challenge is faced in exposing wireless devices to complex data sources, such as Web services, due to the size and complexity of the data structures communicated from such sources and other application development, communication and processing requirements. One type of application which addresses many of theses concerns is a component-based application (CBA) comprising various definitions (data, message, user interface/screen, script etc.) for instructing a runtime environment provisioned on a wireless device. The wireless device may communicate with the data source via a stateful proxy gateway relatively unburdened by the wireless device's processing and storage restrictions which can map communications and handle complex data structures and protocols demanded by the data sources.
Script components developed for the wireless device can detail various business and other logic for communicating with the remote data sources. An application which relies on script functions to conduct a majority of its business logic may be referenced as a script-based application (SBA).
A customizable error-handling (CEH) mechanism, which exposes runtime errors to an application, offers a way for an application to provide its own runtime error-handling logic. For instance, traditional object-oriented languages such as C++ and Java™, as well as the scripting language ECMAScript applies try blocks, catch blocks and (for Java and ECMAScript) finally blocks in order to provide their customizable error-handling feature.
Unfortunately, such a feature in script languages such as ECMAScript (Standard ECMA-262) and JavaScript™ is not perfectly supported in the sense that error objects of ECMAScript can not be inherited to introduce user-defined error objects; instead, an ECMAScript developer has to create his/her own script constructor functions to do this, which is tedious and inefficient and therefore, is not suitable for a fully-fledge business application. Moreover, for each user-defined type of error, a new error object has to be introduced, which is an inefficient “heavy-way” for a wireless application to handle errors. Finally, in a component-based application (CBA), script functions belong just to one type of component of an application, i.e. a script function component, which undertakes the majority of workflow tasks of the application; however, a runtime error can occur not only from script functions, but also from other structural components of component-based application, such as message components. For example, an error can occur when receiving messages because of overflow of an incoming message queue of the application, or the incoming message itself is just an indication of an error that happened in the remote server, which has to be sent to a wireless device. Based on the above considerations, the existing error-handling of scripting languages is not suitable for customizable error-handling in a script-based application running in a mobile device.
The skilled addressee will appreciate that not being able to provide a customizable error-handling mechanism is a great drawback in the case of a script-based application running in a mobile device or in the case of a desktop processing unit since many script-based applications run on these devices.
There is a need for a method and apparatus that will overcome at least one of the above-identified drawbacks.
Features of the present application will be apparent from review of the disclosure, drawings and description of the present application below.
Further details of the present application and its advantages will be apparent from the detailed description included below.